TH> I don't know how many machines you've tested that theory on but
TH> I think if you test on a wide enough sample of machines you'll
TH> find that it won't work reliably. The PC bus hardware was not
TH> designed to share interrupts. When two boards attempt to control
TH> one IRQ the IRQ line will be the average of the two controlling
TH> states (i.e., when one is forcing it active and the other is
TH> forcing it non-active). It's hit-or-miss whether the PIC will
TH> actually see that as an interrupt -- in some
TH> machines/configurations it will, in others it won't.
TH> The IBM PS/2 architecture was designed to share interrupts and
TH> your suggested polling scheme will work quite reliably there.
TH> Also, there are some PC serial port boards that will allow you
TH> to share an IRQ so long as both UARTs sharing the IRQ are on
TH> *that* board.
As you probably read, I posted a couple of messages that, whilst not directly
contradicting the above, could certainly appear that way.
To date I have always used third party stuff when doing any comms work and
the chap who sub-contracted some of that was the person I turned to for guidancein my replies. I showed the above reply of yours to him and he agrees 100%
with your
statement. In fact he indicated that he had meant to qualify it that way
but had not realised I was possibly asking about, not just dual ports, but
dual cards.
TH> Our Async Professional communications library includes the
TH> necessary logic for sharing IRQs but we turn it off by default
TH> simply because the majority of machines out there don't have the
TH> hardware for reliably sharing an IRQ.
Good speaking to you the other night...Hope the package lives up to all reports.
TeeCee
* Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
This is an almost *proverbial* example of wasting time & effort using assembly
language to 'optimize' a routine. Take a look at the code again. The algorithmyou used is: Mem[$A000:y*320+x] := Color. That's OK, it yields the correct
result,
but VERY slowly, due to the "MUL y" instruction.
You should be able to rewrite this WITHOUT using a MUL (or IMUL) instruction!
I give you a clue: offset := y*320+x ==>
offset := y*(256+64)+x
Another clue: y*256 = y shl 8, and
y*64 = y shl 6 = (y shl 8) shr 2
Yet another clue: in a 16-bit word, in some cases you can multiply a value
by 256 by swapping the lower byte with the upper byte
-- No pun intended! --
Regards,
Wilbert
* Origin: Point Wilbert | Verboden Fietsen te plaatsen (2:500/12.10956)
CW> Hello, I'm trying to make an online game, but I have a
CW> problem with disk space- the same problem many bbs's have
CW> with their message bases. If I store all the parts of my
CW> game (192), I get about 95% slack! (Directory entries take
CW> up more space then the files!) So I need to store all my
CW> records in one file...with one variable being unlimited in
CW> length, still being able to get to the next variable!
CW> Something like this:
CW> PlayerList:Record
CW> Name:String[30];
CW> Age:byte;
CW> ..etc..or whatever...
CW> Items:??? {This can be one item, none, or many}
CW> end;
CW> But then have a list of items that doesn't have a minimum or
CW> maximim.. I can do this with an array, but that takes tonnes
CW> of disk space.. plus for the thing I'm doing it's possible
CW> to have 20,000 items or none! So what to do? I was thinking
CW> about pointers, but am not sure how they work entirely and
CW> I'd have trouble writing it...Items:Array[0..0]???
I would advise you to create two files - one with fixed length data and one
with text data. The fixed length file would contain a field with a longint
that gives the file offset of the first text data in the other file that
pertains to that
record. This can be in the form of a linked list if you need to add to
or delete it. You could get really smart and allocate this space in predeterminsize chunks and determine what chunks are available by means of a bitmap.
TeeCee
* Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
